mind_controlfandomcom-20200223-history
Управление доступом на основе ролей
Введение Управление доступом на основе ролей ( ) — развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли. Формирование ролей призвано определить четкие и понятные для пользователей компьютерной системы правила разграничения доступа. Ролевое разграничение доступа позволяет реализовать гибкие, изменяющиеся динамически в процессе функционирования компьютерной системы правила разграничения доступа. Такое разграничение доступа является составляющей многих современных компьютерных систем. Как правило, данный подход применяется в системах защиты СУБД, а отдельные элементы реализуются в сетевых операционных системах. Ролевой подход часто используется в системах, для пользователей которых четко определен круг их должностных полномочий и обязанностей. Не смотря на то, что Роль является совокупностью прав доступа на объекты компьютерной системы, ролевое управление доступом отнюдь не является частным случаем избирательного управления доступом, так как его правила определяют порядок предоставления доступа субъектам компьютерной системы в зависимости от имеющихся (или отсутствующих) у него ролей в каждый момент времени, что является характерным для систем мандатного управления доступом. С другой стороны, правила ролевого разграничения доступа являются более гибкими, чем при мандатном подходе к разграничению. Так как привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя по сути сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем. История Элементарные формы модели RBAC были осуществлены во множестве специальных форм на многих системах, начиная с 1970-х годов. Контроль доступа на основе ролей, используемый в настоящее время происходит из модели, предложенной Ферраильо ( ) и Куном ( ) (1992) и как образцовая модель позже усовершенствованная Санди ( ), Койн, Фейнштейн, и Йоман (1996). * 1992 — статья Ферраильо и Куна, определяющая RBAC посредством доступа только через роли, иерархии и ограничения. формальная модель; * 1994 — DTOS базировал опытный образец RBAC, на прототипе модели прдложенной Ферраильо, Кун, Гаврилья ( ) * 1994 — статья Nyanchama и Osborn определяет модель; * 1994 — файлы IBM (в Европе) первая заявка на патент в области RBAC, цитирующая Ферраильо и Куна; * 1995 — Ферраильо, Кугини ( ), Кун расширили формальную модель, введя определение форм разделения обязанностей; * 1996 — метод Санди для того, чтобы осуществить МАС на основе RBAC; * 1997—1998 — Sybase, Безопасное Вычисление, Siemens объявляет о продуктах RBAC, описанных как базирующиеся непосредственно на модели * 1997 — Безопасное Вычисление включает модель Ферраильо-Куна RBAC в американскую Глобальную Команду DoD и Систему управления; выходит статья Куна на тему разделения обязанностей, необходимых и достаточных условий для безопасности разделения; * 1997 — статья Осборна основанная на отношениях между RBAC и многоуровневой безопасностью мандатной модели политики безопасности; аннотация роли, связывающая RBAC и многоуровневую безопасность * 1998 — RBAC — метод Куна для того, чтобы осуществить RBAC на системе МАС; * 1999 — Барклей ( ), Ферраильо, Кун открывают исходный опытный образец RBAC для развитых веб-серверов; * 2000 — Санди, Ферраильо, Кун публикуют статью, определяющую объединенную модели RBAC, и предлагают стандарт RBAC; * 2004 — Американский Национальный Институт Стандартов, Международный Комитет по Стандартам Информационной технологии (ANSI/INCITS) принимает предложенную Санди, Ферраильо и Куном модель RBAC как единый стандарт. Базовая модель RBAC Для определения модели RBAC используются следующие соглашения: * U = Субъект ( ) = Человек или автоматизированный агент (множество пользователей); * R = Роль ( ) = Рабочая функция или название, которое определяется на уровне авторизации (множество ролей); * P = Разрешения ( ) = Утверждения режима доступа к ресурсу (множество прав доступа на объекты системы); * S = Сессия ( ) = Соответствие между S, R и/или P * UA = Назначение субъекта ( ) * PA: R -> 2p — функция, определяющая для каждой роли множество прав доступа; при этом для каждого p ∈ P существует r ∈ R такая, что p ∈ PA®; ( ) * RH = Частично упорядоченная иерархия ролей ( ). RH может быть еще записана так: ≥ * Один субъект может иметь несколько ролей. * Одну роль могут иметь несколько субъектов. * Одна роль может иметь несколько разрешений. * Одно разрешение может принадлежать нескольким ролям. На возможность наследования разрешений от противоположных ролей накладывается ограничительная норма, которая позволяет достичь надлежащего разделения режимов. Например, одному и тому же лицу может быть не позволено создать учетную запись для кого-то, а затем авторизоваться под этой учетной записью. Используя нотацию теории множеств: * PA \subseteq P \times R , при этом разрешения назначаются связям ролей в отношении «многие ко многим». * SA \subseteq S \times R , при этом субъекты назначаются связям ролей и субъектов в отношении «многие ко многим». * RH \subseteq R \times R Обозначение: x ≥ y означает, что x наследует разрешения y. RBAC Субъект может иметь множество одновременных сессий с различными разрешениями. Возможности и применение Технология управления доступом на основе ролей достаточно гибка и сильна, чтобы смоделировать как избирательное управление доступом (DAC). , так и мандатное управление доступом (MAC) До разработки RBAC, единственными известными моделями управления доступом были MAC и DAC: если модель была не MAC, то она была DAC, и наоборот. Исследования в 90-х показали, что RBAC не попадает ни в ту, ни в другую категорию. Роли создаются внутри организации для различных рабочих функций. Определенным ролям присваиваются полномочия (permissions) для выполнения тех или иных операций. Штатным сотрудникам (или другим пользователям системы) назначаются фиксированные роли, через которые они получают соответствующие привилегии для выполнения фиксированных системных функций. В отличие от управления доступом на основе контекста ( ), реализация RBAC в чистом виде не принимает во внимание текущую ситуацию (такую как, например, откуда было установлено соединение). RBAC отличается от списков контроля доступа ( ), используемых в традиционных избирательных системах управления доступом, тем, что может давать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных. Например, список контроля доступа может предоставить или лишить права записи в такой-то системный файл, но он не может ограничить то, каким образом этот файл может быть изменен. Система, основанная на RBAC, позволяет создать такую операцию как открытие «кредита» в финансовом приложении или заполнение записи «тест на уровень сахара в крови» в медицинском приложении. Присвоение привилегии на выполнение такой-либо операции многозначно, так как операции являются дробящимися в пределах приложения. Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки ( ) средствами RBAC. Таким образом, RBAC может быть основанием и расширением LBAC. В организациях с разнородной IT-инфраструктурой, содержащих десятки и сотни систем и приложений, помогает использование иерархии ролей и наследования привилегий. Без этого использование RBAC становится крайне запутанным. В статье «Дополнительные роли: практический подход к обслуживанию пользователей предприятия»Beyond Roles: A Practical Approach to Enterprise User Provisioning обсуждаются стратегии, альтернативные большому масштабу присвоения привилегий пользователям. Современные системы расширяют старую модель NIST ограничениями RBAC для развертывания на больших предприятиях. Существует несколько академических документов и по меньшей мере одна коммерческая система — Beyond NIST. Для больших систем с сотнями ролей, тысячами пользователей и миллионами разрешений, управление ролями, пользователями, разрешениями и их взаимосвязями является сложной задачей, которую нереально выполнить малой группой администраторов безопасности. Привлекательной возможностью является использование самой RBAC для содействия децентрализованному управлению RBAC. RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R/3 и множество других. Примечания См. также * Информационная безопасность * Проверка подлинности * Lattice-based access control (LBAC), эквивалент Мандатной политики безопасноти (MAC). * Security label * Security classification * Covert channel * Chinese wall * Blind credential * Sudo (s'uper'u'''ser '''do) Unix program * Identity Driven Networking * XACML A Attribute Based Access Control (ABAC) model which incorporates RBAC * grsecurity Ссылки * http://www.ics.utsa.edu Ravi Sandhu, Executive Director and Founder of Institute of Cyber Security, Lutcher Brown endowed chair in Cyber Security Professor of Computer Science and Electrical and Computer Engineering * FAQ on RBAC models and standards * Role Based Access Controls at NIST — huge US government website with lots of information on the theory and implementation of RBAC * XACML core and hierarchical role based access control profile — OASIS XACML standard. (PDF file) * RBAC Microsoft’s article * RBAC .net article * Getting Started with AzMan Категория:Информатика Категория:Защита информации de:Role Based Access Control en:Role-based access control fr:Contrôle d'accès à base de rôles ja:ロールベースアクセス制御 nl:Role Based Access Control pl:Role-based access control vi:Điều khiển truy cập trên cơ sở vai trò